This pull request will create a new dependency on libtorch, so it is difficult to know how to handle that. I think it could be rejected and closed. It is important that once it went out as a pull request and was discussed.

I have not yet fixed spell check, linter, etc., but if there is a chance that the merge will be possible, I will do.

@SakodaShintaro I think that's a reasonable speculation. IMHO it seems OK since CMake won't be built as long as libtorch is not found, but how about creating a Discussion or ask perception team internally?

In my environment, the build failed due to atomicAdd().
I added the following code into hash_3d_anchored.cu based on this link, and it successfully built.

__device__ float atomicAdd(__half * a, float b)
{
  bool uplo =
    ((unsigned long long)a) &
    2;  // check if the atomic is for the upper or lower 16-bit quantity in the aligned 32-bit item
  unsigned * addr = reinterpret_cast<unsigned *>(
    ((unsigned long long)a) & 0xFFFFFFFFFFFFFFFCULL);  // get the 32-bit aligned address
  unsigned old = *addr;
  unsigned val;
  do {
    val = old;
    float newval = __half2float(__ushort_as_half(
                     uplo ? ((unsigned short)(val >> 16)) : ((unsigned short)(val)))) +
                   b;
    unsigned short newval_s = __half_as_ushort(__float2half(newval));
    unsigned newval_u = val & (uplo ? (0x0FFFFU) : (0xFFFF0000U));
    newval_u |= uplo ? (((unsigned)newval_s) << 16) : (newval_s);
    old = atomicCAS(addr, old, newval_u);
  } while (old != val);
  return __half2float(__ushort_as_half(uplo ? (old >> 16) : (old)));
}

In my GPU, I could not run it at 1x speed with the default settings, but it surely performs localization! 👏

The problem about atomicAdd may be described in the following page.

The 32-bit __half2 floating-point version of atomicAdd() is only supported by devices of compute capability 6.x and higher.

https://docs.nvidia.com/cuda/cuda-c-programming-guide/index.html#atomicadd

It may be possible to speed up the process by changing the following constant from 1024 to 512, but I will try this later as I suspect there are other variables that will need to be changed if this is changed.

The problem about atomicAdd may be described in the following page.

The 32-bit __half2 floating-point version of atomicAdd() is only supported by devices of compute capability 6.x and higher.
https://docs.nvidia.com/cuda/cuda-c-programming-guide/index.html#atomicadd

My GPU is a GeForce GTX 1080ti with compute capability 6.1, and it seems like atomicAdd() for __half is not available.
Now I understand. Thanks for sharing the information. 👍

It may be possible to speed up the process by changing the following constant from 1024 to 512, but I will try this later as I suspect there are other variables that will need to be changed if this is changed.

This is the result in my environment.

Exposing MAX_SAMPLE_PER_RAY as a YAML file would be convenient for users. 🙏

Fixed so that sample_num_per_ray can be set from yaml file.

Accuracy is somewhat reduced, but speed is improved.

Wonderful work!. Is there some reference paper about this nerf-based localization methods?

@Gatsby23
Thank you for your interest!

NeRF Part

The code added in this pull request is primarily based on the implementation of F2-NeRF. You can find more information here: https://totoro97.github.io/projects/f2-nerf/

F2-NeRF can be summarized as Instant-NGP enhanced with spatial partitioning via Octree and Warping.

However, this pull request omits the spatial partitioning and Warping using Octree, a key innovation of F2-NeRF, due to the following two drawbacks:

• The initialization process requires about a minute, leading to a time-consuming startup each time.
  It was challenging to backpropagate gradients to the Camera pose for pose optimization.
• Therefore, the process implemented here is almost equivalent to that of Instant-NGP.

NeRF-based Localization Part

This pull request supports two methods of using NeRF for self-localization:

• Scattering self-pose in a Monte Carlo fashion and scoring them by comparing the image reconstructed by NeRF with the actual image.
  • Ref. Loc-NeRF
• Calculating self-pose through differentiation when reconstructing with NeRF.
  • Ref. iNeRF

Neither is a complete reproduction of the paper, but rather a reference of ideas.

I hope this information will help you.

@Gatsby23 Thank you for your interest!

NeRF Part

The code added in this pull request is primarily based on the implementation of F2-NeRF. You can find more information here: https://totoro97.github.io/projects/f2-nerf/

F2-NeRF can be summarized as Instant-NGP enhanced with spatial partitioning via Octree and Warping.

However, this pull request omits the spatial partitioning and Warping using Octree, a key innovation of F2-NeRF, due to the following two drawbacks:

• The initialization process requires about a minute, leading to a time-consuming startup each time.
  It was challenging to backpropagate gradients to the Camera pose for pose optimization.
• Therefore, the process implemented here is almost equivalent to that of Instant-NGP.

NeRF-based Localization Part

This pull request supports two methods of using NeRF for self-localization:

• Scattering self-pose in a Monte Carlo fashion and scoring them by comparing the image reconstructed by NeRF with the actual image.

  • Ref. Loc-NeRF

• Calculating self-pose through differentiation when reconstructing with NeRF.

  • Ref. iNeRF

Neither is a complete reproduction of the paper, but rather a reference of ideas.

I hope this information will help you.

That's really impressive. Beacuase two of the reference paper is worked at a small space. It's really interesting it can worked on a large environment.

Thank you very much. However, it can be said that this method is still in the validation stage, as it has not been fully evaluated to see if it can cover such a large area as a huge city.

NeRF and Gaussian Splatting have developed remarkably in recent years, and there is a possibility that their performance will be enhanced by incorporating methods such as neuralsim and DrivingGaussian.

I look forward to further developments in this area.

Thank you for contributing to the Autoware project!

🚧 If your pull request is in progress, switch it to draft mode.

Please ensure:

• You've checked our contribution guidelines.
• Your PR follows our pull request guidelines.
• All required CI checks pass before marking the PR ready for review.

This pull request has been automatically marked as stale because it has not had recent activity.

In recent years, techniques such as 3D Gaussian Splatting have emerged, and we believe it would be better to start implementing it with offline tools rather than starting with the Autoware runtime, so we are closing this pull request.